プロジェクトマネジメントを複雑に考えないでシンプルに考えてみては？
マイルストーン置いたスケジュールの管理くらいでも良いのかなと。そのマイルストーンの置き方がポイントなんですが。。。
ただ、1番の肝は要件定義。要件洗い出さずにプロジェクト始めるとほぼ失敗します。ゴールが決まっていないのにスタートは出来ませんよね？

そんな事を考えながらプロジェクトを進め、経験しながらプロジェクトマネジメントを学びました。

そんなわけで資格は知りません。

プロジェクトの内容は勿論、人員・サービスの規模に依ると考えます。
また、そのプロジェクトの収束予定期間等。
大規模・長期に渡るマネジメントであればチームの共通言語・ロジックとして何かしらの資格を取得されるのも運用の説得力(信用)の糧になるかもしれません。
少なくとも『情報化』と『マネジメント』は別々の領域であると考えるのが良いかと。

私は自社システムをいくつも立ち上げましたが、プロジェクトマネジメントを正式に学んだことはありません。いつも手探りでした。
そういう講習は”世間一般の”とか”汎用の”を目的に作られていますので、そのうちで自社システム構築に使える部分はそんなに多くないと思います　
例　・講習では要件定義”書”とか仕様”書”とかに、かなり時間が費やされますが自社システム構築であれば”書”を作るのが目的ではないので、”書”に費やすエネルギーを他につかったほうがいいでしょう
例　・自社システム構築では業者との交渉術が必要な場合がありますが講習では教えてくれないですね　良い業者の見つけ方や業者との交渉、社内への説得術、上役への説明、役員会の通し方は経験でしか学べないでしょうね

自社システム構築で私が譲らなかったのは「目的を外さないこと」でした　構築中にはいろいろ障害が起きて身内からも責められることがあります
・当初から開発費はＯＯＯＯ円と言っているのにプロジェクトが進んでくると経営層が恐れをなして「安くしろ」と言ってくる　それに負けて仕様を削ると、実運用ではそこがネックになることがおおい
・文句ばかりのユーザがいて、それの言うことを聞いて仕様をつくるといびつなシステムができる
・ユーザがそっぽを向いてしまうと、なんの意見も出ず、改良もされない
・Ｑは絶対必要、Ｃも安いほうがよいが目的を達成していなければ”銭失い”になる、Ｄは社内システム構築では絶対遵守ではなく問題があれば遅らせてでも解決する

プロジェクトマネジメントは実はどんな仕事にもあると思います　そこでプロジェクトリーダになったつもりで経験を積んでいくとシステム構築でも役立つでしょう　
・自宅を新築するので、さぁ何をしたらよいか
・会社で宴会や行事があるのでどうやって準備・運用したらよいか
・町内会の役員になってしまった　運動会があるがどう準備・運用したらよいか
．．．

私の場合はプロジェクトマネジメントはリーダーから盗みました。
センスの良いリーダーだったので、とても勉強になりました。

一般的にアドバイスするならですが、私は「目的設定」を第一に考えます。
何をしたいのか、どのぐらいしたいのか、いつまでにしたいのか、いくらでしたいのかが中心です。
ここがぶれると、どうにもなりません。まずは、上記の観点から実現できそうなゴールを決定します。
納期を先に決めてしまって品質を気にせず、後で見たら納期を伸ばして品質優先しなかったから目的が達成できませんでした。が良くある失敗例です。

目的設定をしたうえで、次は作業単位に計画を落とし込んでいくのです。
業者に依頼する場合、ある程度は業者がスケジューリングしてくれるでしょう。
ただ、社内の作業はそうはいきません。
誰が、いつ、何を目的に、どうやって、何をするかから全ての作業を設定しましょう。
月単位から週単位へ週単位から日単位へ落とし込んでいきます。
1つポイントになるのは、大体かかるであろう作業工数の1.5倍程度を目安にスケジュールしていきます。
これが作業の遅れが発生した場合などのリスクヘッジになります。

最初に計画を綿密に立ててそれを実施し、終わったら振り返り次回に活かす。
これが一番上達するコツだと思っています。

もう既にご存知かと思いますが、システム開発で一番基本となる考え方はやはり
ウォーターフォール型開発 と思います。

今までこれを手探りでやっていたのであれば、一度振り返ってみて
自社に適応できるように体系を作ってみてはいかがでしょうか。

あとは、きちんとガントチャートやWBSでスケジュールや成果物作成の管理を行うことができればよいとおもいます。

おそらくこれ以上となると、ほかの方のコメントにもﾃﾞあったように、PMBOKやら専門的な知識になってくると思われます。

まずは、今までを振り返り自社に合う体系づくりをお勧めします。

国際標準規格を勉強されてみてはいかがでしょうか。
プロジェクトマネジメントはISO21500で定められていますので、体系的に分類されたプロジェクトマネジメントに対する考え方は大変参考になるかと思います。
質問者様が開発をされていないということですので、既存サービスの導入や運用がメインということであればITサービスマネジメントISO20000-1,2の関連書籍をお読みになることをお勧めします。難解ですが、こちらはITILの考え方を基にした国際規格になりますのでITIL ファウンデーションから学んでみるのも良いかもしれません。

皆さんの意見のとおりかと思いますが、わたくしもコメントをば

私はPMPから学び、習得しましたが、あくまでも成功事例集のサマリみたいなものでそのとおりにプロジェクトが進むわけではないのとプロジェクトの大小により適用がむずかいしいとかあるので、逆にPIMBOKと違うならどういうリスクがおきるのかというのを照らし合わせて実体験を埋めていきました。

また、ウォータフォールでないいわゆるアジャイル的な進め方、もしくは保守のような反復プロセスに対しては、スクラムマスターを習得したのと、いまも継続的に学習しています。こちらはコミュニティも盛んなので現場感ふくめ情報は入りやすいのではないでしょうか？

また、運用フェーズは別でマネジメントが必要なのでITILファンデーションの習得をしました。こちらも実態とは乖離が多いですが、私は考え方や整理のしかたが非常に好きでいまでもプロセスやサービスを考える際には活用しています。

かつ、結局どのマネジメントもプロセスや技法やツールを学ぶに対して、プロジェクトマネジメントには
精神論てきな部分（意思決定のあり方など）が必要でそちは個人的にはこの書籍がいまだに
バイブルです
http://www.amazon.co.jp/dp/4820118587

どの知識体系も知識でしかないので腕を振るうには、体系だった知識があったほうが絶対的に強いとは考えています。しかし、なくてもできることもあるのでちょっとずつ勉強し現場適用してみて成長というものありかとも思います。

追伸
ソフトウェア開発だけいえばipaのこのシリーズも勉強させてもらいましたね
https://www.ipa.go.jp/sec/publish/tn12-006.html

ばっつんさんno

1つポイントになるのは、大体かかるであろう作業工数の1.5倍程度を目安にスケジュールしていきます。
これが作業の遅れが発生した場合などのリスクヘッジになります。
私の場合は1.5倍はつけませんでしたが、かならず何日か何％かの余裕を計画しました　これをマーフィファクターと呼んでいました（「マーフィー」は「マーフィの法則」のマーフィです）

最近、（私がやっていない別のプロジェクトで）マーフィファイクター０のプロジェクトを見かけたので「余裕を見ておかないと失敗するぞ」と忠告したのですが「計画通り進めるのはリーダの務めだ」とか言って聞いてくれませんでした　その結果、順調にすすんだ部分は「余裕が出たからゆっくりやろう」でしたし、要員が病気になって穴の開いた部分は「ダメだこりゃ」的気分でいて、最後の結果報告日まで黙っていて、当日になって大問題になりました　計画通りすすんでいると思い込んでいたリーダは突然の報告にキレてしまいました　各パートの実施順番にまずいところもあって、2か月過ぎた今でも稼働していません
こういう他人の失敗も勉強になります。

立場的に似ているようにおもいます。
私の場合は、基本の基本は独学ですね。

ただ、経験はそれなりに積まれているように思いますので改めて今、基本をやるとかったるさを感じるかもしれません。

転職経験があり、いくつかの職場を経ておもうのはかなり社風に左右されると思います。

学んだ資格はさほどに力を発揮しないこともあるので資格より自らの経験や実績を積むことに注力したほうがよいと思います。

私の経験例だけかもしれませんが、そのたぐいの有資格者はイマイチな人多かったように、おもいます。

本当は、上司や先輩に良い管理者がいれば参考にすることを勧めたいのですが、いないのであれば独学になっちゃいますよね。

すでに書かれていますが、理論面はPMBOKが詳しく、資格で言えばPMPあたりなのでしょうが、欲しいのが資格ではなく知識であるなら、個人的には国家資格のプロジェクトマネージャーも良いですよ。

内容がPMBOKとかぶっていて、教材も探しやすいので勉強しやすいです。ただ、受験内容に論文があるので、資格が欲しいのであれば、ちと難しいかもです。